Summary

• New MinterGuardService that runs after syncMinters() each monitoring cycle
• For any PROPOSED minter not on a committed whitelist (whitelist.{testnet,mainnet}.json, both empty initially), submits denyMinter() within the application period using a signer fetched from Vaultwarden at container start
• Sends a critical Telegram alert for every auto-deny (success and failure)
• Bridges are also denied if not whitelisted; bridge type is inferred from a trivial usd() view call and is therefore unsafe to exempt
• GUARD_ENABLED=false disables the watcher entirely

Signing key handling

• entrypoint.sh uses bw CLI (newly added to the image) to fetch GUARD_PRIVATE_KEY from Vaultwarden on every container start
• Vault password is mounted read-only from the host (/run/secrets/vault-password)
• A per-container copy of the bw appdata dir is mounted from the host so bw sync/bw unlock work without races between containers
• The key never persists on disk — it only exists in the container process env

Test plan

• Build green on CI
• Deploy to dfxdev, verify MinterGuardService logs ENABLED with the expected signer address for both jdt-monitoring and jdm-monitoring
• On Citrea testnet: call suggestMinter() from a non-whitelisted address → expect denyMinter() within one sync cycle, Telegram alert delivered
• Empty-whitelist case: verify a known existing approved minter (already APPROVED in DB) is NOT denied
• Restart the container, verify the key is re-fetched and no GUARD_PRIVATE_KEY leaks into logs